home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 224 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.2 KB
  1. From: Max TenEyck Woodbury <mtew@cds.duke.edu>
  2. Message-ID: <4ere1v$mss@news.duke.edu>
  3. X-Original-Date: 1 Feb 1996 22:15:26 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 02 Feb 96 05:58:44 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Time representations
  9. Organization: Duke University Center for Demographic Studies
  10. References: <4emq2k$ecu@news.duke.edu> <tuivhsd7fn.fsf@nemo.bedford.waii.com>
  11. X-Mailer: Mozilla 1.1N (Windows; I; 16bit)
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMRGoIeEDnX0m9pzZAQF6OQGAkNkLVc2zMqrIfClsxEBZedoUbmkoJP98
  14.     FH1eSWyrERVz5xOSz+affYpGoemLB/xe
  15.     =/HYQ
  16.  
  17. gsez020@nemo.bedford.waii.com (Pete Forman) wrote:
  18. >
  19. >My documentation (IRIX 6.1) gives the range as 0-61.  I presume that
  20. >the current standard does cover leap seconds and that your copy is out
  21. >of date.  I don't understand why it's not 0-60, though.
  22.  
  23.     As noted elsewhere, I was relying on the documentation that went
  24. with a particular implementation.  I have since found other references
  25. that make it clear that his has already covered.  The reason it is 0-61
  26. is because there is a possibility that two leap seconds may be needed at
  27. some future time.
  28.  
  29. >Your remaining points have little relevance.  localtime() and friends
  30. >are indeed only useful for the Gregorian calendar.  If you were to try
  31. >to extend to other calendars you would have difficulty specifying the
  32. >rules.  Days may start at dusk, months according to observations of
  33. >the moon.  Programs can only approximate the future and look up the
  34. >past.
  35.  
  36.     The point is that the current phrasing DOES restrict the standard
  37. to the Gregorian calendar.  I think a little judicious rephrasing might
  38. allow the standard to be used by cultures that do not use the Gregorian
  39. calendar.  The required change might be as simple as noting that the
  40. ranges and definitions apply to the Gregorian calandar and that other
  41. comprable ranges and definitions may be used in locales that use other
  42. calendars.  This would permit but not require other calendar 
  43. implementations.
  44.  
  45.         Max
  46. ---
  47. [ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  48.   Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  49.   is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
  50.